1. Field of the Invention
This invention generally relates to software configuration tracking, and more particularly to techniques performed in a computer system for managing and tracking versions of software tested.
2. Description of Related Art
Generally, software testing is part of the software development process. Software testing may be performed, for example, to test a code modification that adds a new feature or corrects a reported problem. Software systems may rely on software components that are external to the software system, such as a software component provided as part of an operating system as well as various third-party provided software components. Various versions of the same software component may be tested as code is incrementally modified. Additionally, individual developers working on the same product may also modify portions of the same module.
One problem in software testing is tracking different versions or “builds” of a software system that are tested. Obtaining and tracking details of the various system builds may be manually tedious and error prone. Additionally, as more and more test runs are performed, as may be typical in product development, it becomes more difficult to track what version of a software system is associated with a particular test run.
The problem of tracking different software builds is further compounded by indirect dependencies between components. For example, the software system under development might rely on a component A which in turn relies on a component B which in turn also further relies on another component C. Thus, in tracking dependencies and information, the software system being tested is dependent upon a particular version of components A, B and C. The fact that the software system being tested has an indirect dependency upon the C component may not be obvious to developer of the software, for example, as it may be an indirect call to a library provided in an operating system. Thus, tracking software builds may be further complicated by these indirect dependencies.
One technique currently in use is to manually track data describing the various builds that are tested. However, as previously described, one of the drawbacks of this technique stems from the tediousness of tracking even the slightest change in software, and the possibility of a large number of builds as may be typical during software product development. The data gathering may be time consuming as well as error prone. Also, as previously pointed out, another drawback is that it may be difficult to identify all of the indirect dependencies, for example as the previously described software component C. Additionally, the problem may be further compounded in terms of complexity and environment in which shared components such as a shared library may be updated from one of a variety of software package installations. For example, two layered software products may use the same software library. When each of the two layered products are installed, a different version of the same library may be installed on the same computer system. It may be unclear to one using a routine in the library which version is being used. Thus, such installations using shared software components make it difficult and further compound the problem of tracking the various software components associated with a particular build.
Thus, there is required a technique which provides for automatically tracking the various software components of a particular build in accordance with a particular version of a software system being tested.